The Baseline Period
Values from the baseline period are used to calculate projected values.
Overview
The planning grid comes pre-populated with projected values. By default, the projected values are calculated using data from the baseline period. Data from the baseline period is also used to structure your plan. When a plan is created the baseline period is set as the latest complete period. Let's say you create a plan on December 13, 2016 and the latest complete period is November 2016. The baseline period will be set as November 2016 and the plan’s structure will be based on the state of your organization at the end of November 2016.
If you have automatic projected values turned on, then each time you edit your plan values are forecasted for future plan periods. These projected values are calculated based on your edits and the baseline values. When new data is available, you may update the baseline period to project future period plan values. the baseline period to generate projected plan values that are based on the latest actuals. For more information, see Change the Baseline Period.
When you update the baseline period, you'll also be pulling in:
- Exchange rates. The exchange rates from the baseline period of the plan will be used to convert plan currencies.
- Any structural changes to the hierarchal attributes used in your plan segmentation for the selected baseline period.
Note:
- The baseline period can be changed to any historical or partial period.
- You can change the cost model that is used to calculate projected values for a plan in the Edit Configuration dialog. If you're just beginning the workforce planning process, we recommend that you use the budgeted values instead of the actual values for a better planning experience. This is because budget data is more commonly loaded to the solution and it's a dependency for doing cost-based planning, whereas actuals are optional. There can also be significant differences between actuals and budget data that can lead to confusion when configuring segmentation.
Considerations before changing the baseline period
Updating the baseline period allows you to pull in the latest changes from your organization including any structural changes. It's important to understand the type of structural changes in your source data that we support and any actions that may be required before you update your baseline period.
Supported structural changes
This section provides examples of the structural changes that we support and what to expect in your plan after the baseline period is updated. Depending on the extent of the structural changes and the number of new members being added or deleted from the source system, you may have to reconcile the changes that are detected after choosing your new baseline period.
| Structural Changes in the Source Data | How Plans are Impacted |
|---|---|
| A attribute that is included in your plan segmentation gets a new member. For example, Sales was added to the Job Family attribute. |
|
| An existing, unpopulated attribute member under a segment becomes populated. For example, the number of Sales employees in Europe increased from 0 to 3. |
|
| The Organization Hierarchy that is included in your plan segmentation is changed. For example, a segment changes parents but not levels. |
|
| The Organization Hierarchy that is included in your plan segmentation is changed. For example, a segment changes parents and levels. |
|
| A segment is renamed in the source data. | The display name for the segment will automatically update. |
| A segment's ID is changed in the source data. |
|
| Structural changes that result in the addition or removal of segments in a subplan. |
|
|
Members of the plan context have moved up a level inside their hierarchy and the same hierarchy is used in the plan segmentation. Imagine an organization with the following structure at the time of plan creation:
Let’s say the plan context is set to Product and your plan segmentation includes Organization Hierarchy level 4 and 5. Then there is a reorganization where Product moves out of Research and Development and under Bluesphere:
In this example, Product moves up in the Organization Hierarchy from level 3 to level 2. |
Prior to the reorganization, members of Product at level 4 and 5 were included in the plan. To ensure these members remain in the plan, the plan segmentation is expanded to include Organization Hierarchy level 3. As a result, the new plan segmentation is Organization Hierarchy level 3 to level 5. Note: We will only expand the segmentation where the reorganization occurs. In this example, if Cost Center Hierarchy Level 2 was also included in your plan segmentation, we would not expand the Cost Center Hierarchy. |
|
Members of the plan context have moved down a level inside their hierarchy and the same hierarchy is used in the plan segmentation. Imagine an organization with the following structure at the time of plan creation:
Let’s say the plan context is set to Product and your plan segmentation includes Organization Hierarchy level 3 and 4. Then there is a reorganization where Product moves under Research and Development:
In this example, Product moves down in the Organization Hierarchy from level 2 to level 3. |
Prior to the reorganization, members of Product at level 3 and 4 were included in the plan. To ensure these members remain in the plan, the plan segmentation for Organization Hierarchy is shifted down a level to Organization Hierarchy level 4 and 5. Note: We will only shift the segmentation where the reorganization occurs. In this example, if Cost Center Hierarchy Level 2 was also included in your plan segmentation, we would not shift the Cost Center Hierarchy. |
Unsupported structural changes
During plan creation, you can define the plan context to select a specific part of your organization that you want to plan for. The plan context cannot be changed once the plan is created. As a result, you will not be able to update the baseline period if the members that you've selected for the plan context no longer exist in the source data. For example, if a member ID is changed in the source data and the member is part of your plan context, you will not be able to update the baseline period because the plan context cannot be changed.
Best practices
Follow these tips to reduce the issues and conflicts that may occur when you update the baseline period of your plan:
- Avoid updating IDs in the source data. We recommend that you update display names instead because these changes can be easily remapped to your plan data.
- Do not include level information in the IDs of your source data. For example, don't give a member the ID of L3_Sales. If the member changes levels, you'd also have to change the ID.
- Avoid incorporating large structural reorganizations into your plan as these changes are hard to predict and support.
- Use data that will remain relatively stable in your plan segmentation. Using stable data reduces the amount of potential conflicts and manual reconciliation you'll have to do each time you update your plan baseline. Changes are inevitable but segmenting your plan by Organization Hierarchy instead of Supervisory Hierarchy will reduce the amount of work that you and your subplanners have to do to update the plan’s structure when the baseline period is updated.
- Avoid using data that might change in your plan's context because this cannot be updated once the plan is created. For example, we recommend that you filter on the Country "USA" instead of the Organization structure "USA" for your plan context.